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System  Documentation 
For 

Estimating  Supplies  Program  (ESP) 


1 .  Introduction 

This  document  describes  the  development  process  and  functionality  of  the  Estimating  Supplies 
Program  (ESP). 

1.1  Background 

The  Naval  Health  Research  Center  (NHRC)  designed,  developed,  and  utilized  a  systematic 
process  to  review  the  U.S.  Marine  Corps  medical  supply  requirements.  This  approach  identified 
the  medical  tasks  required  to  treat  patients  with  specific  injuries  and  illnesses,  and  determined 
the  supplies  and  equipment  required  by  each  task.  To  determine  the  amount  of  consumable 
supply  requirements,  a  patient-generating  model  was  used  to  project  the  frequency  of  specific 
injuries  and  illnesses  likely  to  occur  in  theater.  Substantial  reductions  (approximately  30%)  in  the 
number  of  items,  weight,  and  cube  were  achieved.  By  establishing  the  clinical  requirement  for 
each  item  pushed  forward,  the  NHRC  model  was  able  to  reduce  the  logistical  burden  carried  by 
Marine  Corps  units  and  enhance  far-forward  clinical  capability.  One  result  of  this  research  is  an 
extensive  database  that  catalogues  patient  conditions  (PCs)  and  the  tasks  and  supplies  required  to 
treat  them.  NHRC  has  incorporated  the  research  and  the  database  into  ESP  to  provide  users  with 
the  ability  to  calculate  the  supplies  and  equipment  needed  to  treat  a  particular  patient 
distribution. 

1.2  Purpose 

This  system  documentation  is  written  to  assist  ESP  users  with  planning  medical  resource 
requirements  and  to  help  ESP  system  administrators  at  NHRC  with  maintenance  of  the  database 
and  enhancements  in  program  capability.  It  may  also  be  used  to  perform  an  independent 
verification  and  validation  of  system  capabilities. 

1.3  Scope 

ESP  uses  casualty  estimates,  levels  of  care,  and  functional  areas  to  calculate  the  supplies 
necessary  to  treat  a  defined  patient  stream.  ESP  is  capable  of  offering  the  following  levels  of 
care:  First  Responder,  Battalion  Aid  Station  (BAS),  Forward  Resuscitative  Surgery  (FRS)/Shock 
Trauma  Platoon,  Surgical  Company  (SC),  Small  Ships/Independent  Duty  Corpsman, 

Submarines,  Landing  Ship  Dock/General  Medical  Officer,  LHA/LHD,  and  Aircraft  Carriers. 

ESP  also  offers  the  functional  areas  present  at  each  specific  level  of  care,  and  it  may  be  expanded 
to  cover  all  the  listed  levels  and  their  respective  functional  areas  in  the  future. 

1.4  Overview 

This  document  contains  a  general  description  of  ESP,  and  detailed  descriptions  of  its  features 
and  performance,  design  considerations,  interfaces,  security,  delivery,  installation,  maintenance, 
and  future  development  opportunities. 


2 


2.  Hardware  Interfaces 


The  system  should  run  on  any  IBM-compatible  personal  computer,  provided  that  it  meets  the 
minimum  required  configuration.  A  variety  of  printers  are  supported. 


Hardware 

Minimum 

Preferred 

Processor 

386 

Pentium  class 

MB  RAM 

16 

32 

3.  Software  Interfaces 

This  table  shows  the  minimum  software  needed  and  the  configuration  of  software  preferred  to 
run  the  application.  Windows  NT  and  Windows  95/98  are  the  assumed  operating  systems.  The 
on-line  Help  system,  built  using  Microsoft  HTMLHelp,  works  with  Internet  Explorer  (IE)  4.0  or 
higher.  Furthermore,  it  is  beneficial  to  the  user  to  have  Microsoft  Word  and  Excel  to  view  ESP 
output. 


Software 

Minimum 

Preferred 

Operating  System 

Windows  95  or  NT3 

Windows  98  or  NT4 

MS  Office 

97 

97  or  2000 

Web  Browser 

EE4 

IE5 

4.  Communications  Interface 

ESP  uses  SMTP  email  client  to  email  results  of  queries  and  reports  to  any  recipient. 


5.  Delivery  and  Installation 

The  program  espsetup.exe  may  be  downloaded  from  the  NHRC  Web  site  (www.nhrc.navy.mil) 
under  Modeling  and  Simulation  Program,  Resource  page.  The  user  must  then  run  espsetup.exe 
from  his  or  her  local  drive  to  install  the  program. 

1 .  Close  all  applications  in  use  on  the  machine. 

2.  Download  espsetup.exe  from  the  Web  site. 

3.  Run  espsetup.exe.  The  user  chooses  the  location  to  save  it  in. 

4.  Restart  the  computer. 

5.  Run  the  executable  se_l.exe  to  open  ESP. 

Log  in  and  password  are  required  to  enter  the  program. 


6.  General  Description  of  ESP 


ESP  allows  the  user  to  either  generate  the  supplies  required  to  treat  a  patient  stream  in  the  form 
of  an  ESP  report,  or  to  query  the  database  to  learn  about  the  relationship  among  PCs,  tasks,  and 
supplies  at  specific  functional  areas  in  the  form  of  an  ESP  query.  The  former  requires  a  scenario, 
while  the  latter  does  not. 

To  run  an  ESP  report,  the  user  must  establish  a  patient  stream  by  selecting  a  defined  scenario, 
copying  and  modifying  a  scenario,  building  a  new  scenario,  or  importing  a  scenario  from  an 
outside  data  source,  such  as  an  Excel  spreadsheet.  In  each  method,  the  user  identifies  a  patient 
stream  consisting  of  injuries  and  illnesses  most  likely  to  occur  in  deployments  and  conflicts,  and 
selects  level  of  care  and  functional  area.  ESP  uses  these  inputs  to  determine  the  tasks  to  be 
performed  and  the  concomitant  supplies  to  be  consumed  in  order  to  render  care.  The  user  may 
output  these  program  results  in  many  formats  (e.g.,  Word  document,  Excel  spreadsheet,  or 
printed  report).  The  user  may  also  email  the  results  to  a  specified  recipient.  Figure  1  shows  the 
data  flow  diagram. 


Figure  1.  Data  Flow  Diagram 
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To  execute  an  ESP  query,  the  user  must  select  level  of  care  and  functional  area,  and  the  type  of 
query  to  run.  For  example,  ESP  queries  can  determine  the  tasks  performed  to  treat  a  selected  PC 
or  the  supplies  required  to  perform  a  certain  task. 

6.1  Product  Perspective 

The  system  was  developed  using  Microsoft  Visual  Studio  6.0.  The  tables,  forms,  libraries, 
reports,  and  queries  were  all  designed  using  Visual  FoxPro  (VFP  6.0).  Data  are  stored  in  VFP 
tables  and  retrieved  using  VFP  queries  and  reports. 

The  design  philosophy  was  to  build  an  application  that  could  use  output  from  other  software 
applications,  such  as  casualty  estimating  programs,  in  severed  formats,  and  provide  output  in 
these  same  formats.  The  input  and  output  of  this  software  includes  Excel  spreadsheets,  ASCII 
comma  separated  files  and  text  files,  dBase,  FoxPro,  Microsoft  Word,  and  HTML  tables. 


6.2  User  Characteristics 


Anticipated  users  include  individuals  participating  in  training  exercises,  medical  personnel 
conducting  Authorized  Medical  Allowance  List  (AMAL)  reviews,  and  NHRC  systems 
administrators  maintaining  the  database.  The  user  should  be  familiar  with  computers  and  the 
Windows  operating  system.  In  order  to  run  ESP,  the  user  must  be  able  to  choose  a  defined 
scenario,  build  a  patient  stream  by  entering  a  number  of  patients  for  each  PC,  or  build  a  patient 
stream  by  identifying  how  many  patients  are  exhibiting  each  injury  or  disease  type.  The  user 
must  also  select  the  level  of  care  and  functional  areas  where  casualties  receive  treatment. 

The  structure  of  the  system  is  based  on  two  levels  of  access.  The  first  level  user  (level  1)  is  a 
program  developer  who  has  access  to  data  maintenance  functions.  The  second  level  user  (level  0) 
is  an  end  user  of  the  estimating  software  who  does  not  have  direct  access  to  database  tables.  This 
structure  was  created  to  maintain  database  integrity.  Furthermore,  all  users  enter  a  password  to 
enter  the  system  (See  Section  9,  Security). 

6.3  General  Constraints 

While  many  maintenance  capabilities  are  built  into  the  application,  any  significant  system 
modification  or  enhancement  must  be  performed  by  someone  familiar  with  VFP  6.0.  NHRC 
administrators  will  perform  quarterly  maintenance  on  the  databases  and  provide  updated 
installation  packages  as  well  as  upgraded  software. 


7.  Features 

The  following  sections  describe  specific  ESP  features,  inputs,  processing,  outputs,  and  data  (see 
Figure  2). 

7. 1  Specific  Features 

Where  practical,  the  system  attempts  to  prevent  invalid  data  entry  upon  input.  For  example, 
when  a  user  fails  to  select  a  PC  but  attempts  to  generate  a  query  requiring  one  as  a  parameter,  the 
system  reminds  the  user  to  enter  a  PC. 

There  are  many  calculations  involved  in  determining  the  supplies  necessary  for  a  given  patient 
stream.  By  storing  the  necessary  information  in  tables,  ESP  queries  the  tables  to  get  a  result  set. 
The  tables  used  in  the  processing  of  PCs,  tasks,  and  supplies  are  maintained  by  NHRC  and  may  be 
updated  on  occasion  to  include  new  functional  areas,  revised  treatments,  new  technology,  or  new 
injury  or  disease  types.  An  algorithm  is  used  to  calculate  the  supply  estimation  necessary  for  a 
given  patient  stream  for  all  of  the  PCs. 

For  all  PCs,  sum  the  following: 

(number  of  patients  *  [Initial  use  *  IPTS1]  *  quantity)  +  (number  of  patients  *  [Recur2  *  IPTS1  * 
{ALOS3/24}  -  1]  *  quantity) 

'IPTS  is  percentage  of  patients  with  a  specific  PC  who  require  a  specific  task. 

2  Recur  is  the  number  of  times  the  task  is  repeated  after  the  first  day  of  treatment. 

3ALOS  is  the  Average  Length  of  Stay  measured  in  hours. 


Figure  2.  ESP  Step-by-Step 

Please  note:  Dotted  lines  indicate  tables  used  by 
queries .  Solid  lines  indicate  tables  used  by  reports . 
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7.2  Inputs 

The  user  has  the  option  to  select  a  predefined  scenario  created  by  NHRC  (e.g.,  Northeast  Asia, 
Heavy  Battle  Intensity).  The  user  may  also  copy  an  existing  scenario  and  modify  it,  import  a 
patient  stream  from  another  data  source  (e.g.,  Excel  spreadsheet  or  ASCII  text  file  created  by  a 
casualty  estimator),  or  build  a  new  scenario. 

If  the  user  chooses  to  build  a  new  scenario,  s/he  may  either  enter  the  number  of  patients 
exhibiting  each  PC  or  enter  the  total  number  of  casualties  by  injury  and  disease  type.  The  user 
must  also  enter  level  of  care  and  functional  area,  having  the  option  to  report  on  a  subset  of  the 
selected  functional  areas.  Scenarios  are  saved  upon  creation  and  users  may  then  add,  modify,  or 
delete  scenarios  they  create.  Users  may  not  modify  nor  delete  scenarios  created  by  another  user. 
See  the  ESP  User’s  Guide  for  more  information  on  system  capabilities. 

7.3  Processing 

When  the  user  [se_user]  starts  ESP,  s/he  must  decide  whether  to  work  with  a  scenario  or  query 
the  database.  If  working  with  a  scenario,  the  user  must  select  a  listed  scenario,  import  an  existing 
scenario  from  another  file,  or  build  a  new  one  [se_scen].  Regardless  of  the  selected  option,  the 
user  must  input  level  of  care  and  functional  area,  and  typically  does  so  before  actually  building 
the  patient  stream.  [se_loc]  is  a  table  that  lists  the  available  level  of  care  (e.g.,  First  Responder, 
BAS,  SC),  while  table  [se_fas]  lists  the  available  functional  areas  (e.g.,  Triage,  Operating  Room, 
Ward).  Once  the  user  chooses  the  desired  inputs,  ESP  stores  them  in  the  [se_scfa]  table. 

When  the  user  chooses  to  import  a  scenario,  the  data  are  copied  to  a  .dbf  file  with  the  same  name 
as  the  source  file.  The  [se_scen]  and  [se_strm]  tables  are  populated  directly  from  the  .dbf  file. 

When  the  user  builds  or  modifies  a  scenario  by  PC,  ESP  references  both  the  [se_pc]  table  that 
lists  all  available  PCs  by  code  number  (e.g.,  PC  001  is  cerebral  concussion  closed  with/without 
nondepressed  linear  skull  fracture  severe — loss  of  consciousness  from  2  to  12  hours),  and  the 
[se_cats]  table  that  lists  PCs  by  category.  The  PCs  selected  by  the  user  are  stored  in  the 
[se_strm]  table.  This  table  also  contains  the  integral  number  of  patients  and  the  probability  of 
these  patients  exhibiting  the  PC. 

When  the  user  builds  a  scenario  by  injury  and  disease  type,  ESP  references  the  [sejbyinj]  table. 
This  table  stores  the  probabilities  of  casualties  exhibiting  injury  and  disease  conditions  by 
geographical  location,  how  the  condition  occurred  (e.g.,  wounded  in  action  [WIA],  nonbattle 
injury  [NBI],  disease),  type  of  condition  (e.g.,  bum,  inhalation),  and  physical  location  (e.g.,  arm, 
head).  The  user  selects  casualties  by  these  same  criteria  and  the  data  are  stored  in  the  [sejbuild] 
table.  The  available  injury/disease  types  are  assigned  a  PC  code.  A  probability  is  used  to 
simulate  a  fractional  (noninteger)  number  of  patients  between  zero  and  one  (this  situation  may 
also  occur  when  importing  data  from  an  external  source  with  noninteger  patients).  Then  ESP 
divides  the  number  of  patients  by  the  PCs  assigned  to  that  injury  or  disease  type.  However,  the 
number  of  patients  may  not  be  evenly  divisible  by  these  PCs.  If  there  is  more  than  one  patient, 
the  system  rounds  off  to  the  nearest  integer.  To  avoid  eliminating  PCs  or  overestimating  required 
supplies,  the  system  converts  patient  numbers  with  the  value  of  less  than  one  to  a  probability, 
and  replaces  the  number  of  patients  with  one.  As  a  result,  the  total  number  of  patients  may 
slightly  exceed  the  projected  total  of  patients. 


At  this  point,  the  user  has  completed  building  the  patient  stream.  To  generate  a  list  of  tasks 
associated  with  each  PC  in  each  functional  area,  ESP  cross  references  the  [se_strm]  table  with 
the  [se_task]  table,  which  lists  all  existing  tasks  required  for  the  treatment  of  each  PC.  The  result 
of  this  cross-reference  is  stored  in  [se_pctsk]  as  the  list  of  tasks  required  to  treat  the  patient 
stream.  [se_pctsk]  also  contains  the  number  of  times  the  task  is  performed  on  Day  1,  the  number 
of  times  it  is  repeated  on  Day  2  and  every  subsequent  day,  the  percentage  of  times  the  task  is 
performed  for  the  specific  PCs,  the  average  length  of  stay  of  a  patient,  and  the  treatment  time. 

Each  task  has  a  list  of  supplies  required  for  performance  at  each  functional  area.  The  [se_supp] 
table  is  a  list  of  supplies  that  includes  nomenclature,  National  Stock  Number  (NSN),  weight, 
cube,  cost  and  type  (ECD:  equipment,  consumable,  durable).  Units  of  measure  are  stored  in 
[se_units]  table  and  equipment  items  are  listed  in  the  [se_equip]  table.  The  quantities  of  each 
supply  required  for  each  task  performed  at  each  functional  area  are  extracted  from  the  [se_pcfts] 
table. 

The  user  now  typically  runs  a  report  on  the  scenario  (ESP  still  allows  the  user  to  select  a  query,  if 
desired).  Several  reports  offer  ordering  and  subtotaling  features  and  also  allow  the  user  to  report 
on  a  subset  of  the  selected  functional  areas.  Lastly,  the  user  identifies  the  desired  format  of  the 
output  (e.g..  Word,  Excel)  as  well  as  how  to  receive  this  output  (e.g.,  save,  print,  email). 

7.4  Outputs 

ESP  offers  two  types  of  output:  reports  and  queries.  A  report  includes  data  that  are  relevant  to  a 
defined  patient  stream.  A  query  is  information  from  the  ESP  database  that  is  not  dependent  on  a 
patient  stream.  Output  is  formatted  landscape  or  portrait,  depending  on  which  orientation  best 
suits  the  data  displayed.  Orientation  is  determined  by  the  selection  of  the  report/query  and  cannot 
be  altered  by  level  0  users. 

REPORTS 

SUPP1  Supplies  for  Current  Scenario 

SUPPDET  Detailed  Analysis  of  Supplies 

PATSTRM  Patient  Stream  for  Current  Scenario 

QUERIES 

PCTASK  Patient  Conditions  for  a  Selected  Task 

SUPPTASK  Supplies  for  a  Selected  Task 

SUPCTASK  Patient  Conditions  and  Supplies  for  a  Selected  Task 
Note:  The  user  may  enter  text  to  search  for  a  specific  task . 

PCSUPP  Patient  Conditions  Requiring  a  Supply 

TASKSUPP  Tasks  Requiring  a  Supply 

PCTKSUPP  Patient  Conditions  and  Tasks  for  a  Supply 

Note:  The  user  may  enter  the  last  4  digits  of  the  NSN  to  search  for  a  specific  supply. 

TASKPROF  Task  Profile  for  a  Patient  Condition 
SUPP3  Supplies  for  a  Patient  Condition 

SUPP2  Tasks  and  Supplies  for  a  Patient  Condition 

Note:  The  user  may  enter  text  to  search  for  a  specific  PC. 

The  program  listings  are  included  in  Appendix  A  of  this  document. 


7.5  Data 

The  data  entered  by  the  users  and  the  data  used  to  calculate  results  are  stored  in  Visual  FoxPro 
tables  contained  in  a  database.  The  stored  procedures  in  this  database  include  a  function  to  assign 
new  unique  keys  when  records  are  added  to  tables.  Most  tables  also  have  a  unique  key  field  that 
contains  a  unique  value  generated  by  ESP  to  help  maintain  data  integrity. 


DATABASE  DOCUMENTATION 


♦  USER 

The  se_user  table  is  used  to  store  data  about  users.  The  name,  password,  and  user  level  are  included. 


Field 

Name 

Short  Name 

Description 

Values 

user_id 

user  ID 

unique  identifier  of  the  user 

autogenerated  integer 

username 

user  name 

name  of  user 

text  user  input 

userpass 

user  password 

encrypted  password  of  user 

alphanumeric 

userlvl 

user  level 

level  of  access  granted  to  the  user 

0  or  1 

♦  BUILDING  A  SCENARIO 


The  sejbyinj  table  is  used  to  build  a  scenario  by  injury  or  disease  type. 


Field 

Name 

Short  Name 

Description 

Values 

byinj_id 

by  injury  or  disease 

ID 

a  unique  identifier  of  the 
record  in  se_byinj 

autogenerated  integer 

catl_id 

category  1  ID 

nothing,  injury,  or  disease 

catl_id  from  se_catl 

cat2_id 

category  2  ID 

injury  or  disease  type  ID 

cat2_id  from  se_cat2 

cat3_id 

category  3  ID 

injury  or  disease  location  ID 

cat3_id  from  se_cat3 

cat4_id 

category  4  ID 

specific  location  ID 

cat4_id  from  se_cat4 

geo_id 

geographic  ID 

identifies  geographical 
location  of  injury  or  disease 

NE  Asia,  SWAsia,  NATO, 
etc. 

wnd_id 

WIA,  NBI,  disease 

identifies  type  of  injury 

1,  2,  or  3 

pc_id 

PC  ID 

patient  condition  ID 

pc_id  from  se_pc 

byinj_pro 

probability 

encrypted  probability  of 
injury  or  disease  occurring 

numeric  value  from  0  to  100 

The  se_scen  table  is  used  to  store  information  about  the  scenarios.  It  also  identifies  who  created 
the  scenario  and  stores  a  short  description  of  the  scenario. 


Field 

Name 

Short  Name 

Description 

Values 

scen_id 

scenario  ED 

unique  identifier  of  records  in  the  table 

autogenerated  integer 

scenario 

scenario 

short  name  of  scenario 

text 

scendesc 

scenario 

description 

long  name  of  scenario  to  be  displayed  to 
users 

text 

user_id 

user  ID 

the  ID  of  the  user  who  created  the 
scenario 

user_id  from  se_users 

avail 

available 

is  the  scenario  available  to  users 

true  or  false 

scen_type 

scenario  type 

type  of  scenario  based  on  how  it  was  built, 
patient  condition,  injury  or  disease 

pc  or  id 

scen_memo 

scenario 

memo 

comments  about  the  scenario,  more 
detailed  description,  or  origin  information 

memo 

♦  LEVEL  OF  CARE 

The  se_loc  table  is  used  to  store  the  level  of  care  information  that  has  been  selected  by  the  user. 


Field 

Name 

Short  Name 

Description 

Values 

loc_id 

LOCID 

unique  identifier  of  the  level  of 
care 

autogenerated  integer 

locdesc 

LOC  description 

name  to  be  displayed 

text 

loccode 

LOC  code 

short  code  to  be  displayed 

text 

service 

branch  of  service 

branch  of  service 

text 

loc_seq 

LOC  sequence 

sequence  to  be  displayed 

autogenerated  integer 

rep_loc 

report  LOC 

current  report  includes  this  level 
of  care 

true  or  false 

avail 

LOC  available 

is  the  level  of  care  available  to 

users 

true  or  false 

♦  FUNCTIONAL  AREA 

The  se_scfa  table  is  used  to  store  information  about  the  functional  areas  selected  for  each 
scenario. 


Field 

Name 

Short  Name 

Description 

Values 

scen_id 

scenario  ED 

unique  identifier  of  records  in  the  table 

scen_id  in  se_scen 

fa_id 

FA  ID 

functional  area  ID 

fa_id  in  se_fas 

The  se_impfa  table  is  used  to  identify  which  functional  areas  are  to  be  imported  for  which 
scenarios. 


Field 

Name 

Short  Name 

Description 

Values 

imprg_id 

import  program  ID 

import  program  ID 

imprg_id  from  se_imprg 

fa_id 

FA  ID 

functional  area  ID 

fa_id  from  se_fas 

The  se  fas  table  is  used  to  store  functional  areas  and  level  of  care. 


Field 

Name 

Short  Name 

Description 

Values 

fa_id 

FA  ID 

a  unique  identifier  of  functional 
area 

autogenerated  integer 

fa 

FA 

character  functional  area  used 
to  relate  it  to  the  old  system 

text 

fa_desc 

FA 

full  name  of  the  functional  area 

text 

ech 

echelon  code 

short  code  for  the  echelon  in  the 
old  system 

two  characters 

old_fa 

Old  FA 

functional  area  ID  for  the 
original  version  of  ESP 

autogenerated  integer 

loc_id 

LOCID 

level  of  care  ID 

loc_id  from  se_loc 

include 

include  the  FA 

include  the  functional  area  in 
the  current  scenario 

true  or  false 

increp 

include  FA  in  report 

include  functional  area  in  report 

true  or  false 

avail 

make  FA  available 

make  functional  area  available 

to  user 

true  or  false 

incimp 

include  FA  in  import 

include  functional  area  in 
import 

true  or  false 

fa_seq 

FA  sequence 

functional  area  sequence  to 
display 

autogenerated  integer 

♦  PATIENT  STREAM 

The  lv_addpcs  local  view  is  used  to  add  patient  condition  to  a  patient  stream. 


Field  Name 

Short  Name 

Description 

Values 

pc_id 

PC  ID 

a  unique  identification  of  the  patient 
condition 

pc_id  from  se_pc 

KSS&9HHI 

category  ID 

unique  identifier  of  category 

cat_id  from  se_cats 

pc 

PC  number 

the  character  number  from  the  old 
patient  condition  numbering  scheme 

001  to  350 

pcdesc 

PC  description 

description  of  the  patient  condition 

any  text 

num_pat 

number  of 
patients 

number  of  patients  with  the  patient 
condition  that  should  be  added  to  the 
patient  stream 

autogenerated  integer 

The  sejbuild  table  is  used  to  build  a  patient  stream  by  injury  or  disease  type  with  a  desired  level 
of  detail.  For  instance,  the  user  can  choose  an  injury  type  (i.e.,  fracture),  the  location  of  the  injury 
(i.e.,  upper  extremity),  and  the  specific  location  (i.e.,  forearm). 


Field 

Name 

Short  Name 

Description 

Values 

bld_id 

build  ID 

a  unique  identifier  of  the 
record  in  se_build 

autogenerated  integer 

scenjd 

scenario  ID 

a  unique  identifier  of  the 
scenario  being  built 

scen_id  from  se_scen 

wnd_id 

WIA,  NBI,  disease 

identifies  type  of  injury 

1,  2,  or  3 

geo_id 

geographic  ID 

identifies  geographical 
location  of  injury  or  disease 

NE  Asia,  SWAsia,  NATO, 
etc. 

bld_num 

number 

number  of  patients  with  the 
injury  or  disease 

autogenerated  integer 

catl_id 

category  1  ID 

nothing,  injury,  or  disease 

catl_id  from  se_catl 

bld_inj 

injury  or  disease 

character 

cat_l  from  se_catl 

category  2  ID 

injury  or  disease  type  ED 

cat2_id  from  se_cat2 

ESSS95SH 

injury  or  disease  type 

type  description 

cat_2  from  se_cat2 

cat3_id 

category  3  ED 

injury  or  disease  location  ID 

cat3_id  from  se_cat3 

bld_loc 

injury  or  disease 
location 

location  description 

cat_3  from  se_cat3 

category  4  ED 

specific  location  ED 

cat4_id  from  se_cat4 

bld_spec 

specific  location 

specific  location  description 

cat_4  from  se_cat4 

The  se_catl  table  is  used  by  many  functions  in  the  application  to  differentiate  between  injury 
and  disease  at  the  highest  level. 


Field 

Name 

Short  Name 

Description 

Values 

catl_id 

category  1  ED 

nothing,  injury,  or  disease 

0,1,2 

cat_l 

category  1 

character  nothing,  injury,  or  disease 

text 

The  se_cat2  table  is  used  to  classify  injuries  and  diseases  into  types  of  resources. 


Field 

Name 

Short  Name 

Description 

Values 

cat2_id 

category  2  ED 

a  unique  identifier  of  category  2 

autogenerated 

integer 

cat_2 

description  of  the  type  of  injury  or  disease 

text 

The  se_cat3  table  is  used  to  further  classify  injury  or  disease  types  by  bodily  location  of  injury. 


Field 

Name 

Short  Name 

Description 

Values 

cat3_id 

category  3  ID 

a  unique  identifier  of  category  3 

autogenerated 

integer 

cat_3 

category  3 

description  of  location  of  injury  or  disease 

text 

The  se_cat4  table  is  used  to  further  classify  injury  or  disease  types  by  specific  bodily  location. 


Field 

Name 

Short  Name 

Description 

Values 

cat4_id 

category  4  ED 

a  unique  identifier  of  category  4 

autogenerated 

integer 

cat_4 

category  4 

description  of  location  of  injury  or  disease 

text 

The  se_cats  table  is  used  to  classify  injuries  and  diseases. 


Field 

Name 

Short  Name 

Description 

Values 

cat_id 

category  ID 

a  unique  identifier  of  category 

autogenerated 

integer 

category  code 

short  name  of  category 

text 

description  of  category 

text 

cat_seq 

category 

sequence 

sequence  of  category  for  display 

autogenerated 

integer 

The  se_strm  table  is  used  to  store  information  about  the  patient  streams  when  building  by  injury 
or  disease. 


Field 

Name 

Short  Name 

Description 

Values 

strm_id 

stream  ID 

unique  identifier  of  the  stream  table 

autogenerated  integer 

scen_id 

scenario  ID 

unique  identifier  of  scenario 

scen_id  in  se_scen 

pc_id 

PC  ID 

unique  identifier  of  the  patient  condition 

pc_id  in  se_pc 

prob 

probability 

probability  of  the  patient  condition 
occurring  in  the  scenario 

numeric 

num_pat 

number  of 
patients 

number  of  patients  exhibiting  the  patient 
condition  in  the  scenario 

numeric 

♦  PATIENT  CONDITIONS 

The  se_pc  table  contains  the  patient  conditions. 


Field 

Name 

Short  Name 

Description 

Values 

pc_id 

PC  ID 

patient  condition  ID 

autogenerated  integer 

cat_id 

category  ID 

category  that  the  patient  condition 
fits 

cat_id  from  se_cats 

pc 

PC 

old  patient  condition  to  allow 
matching  old  system 

four  character 

pcdesc 

PC  description 

patient  condition  description 

text 

num_pat 

number  of  patients 

number  of  patients  with  the  patient 
condition  a  temporary  field 

numeric 

i 

The  Ivjbyinj  is  a  local  view  used  to  capture  the  injury  types  and  assign  probabilities. 


Field 

Name 

Short  Name 

Description 

Values 

catl_id 

category  1  ID 

main  category  injury  or  disease 

catl_id  from  se_catl 

cat2_id 

category  2  ID 

types  of  injuries  or  diseases 

cat2_id  from  se_cat2 

cat3_id 

category  3  ID 

location  of  injury  or  disease 

cat3_id  from  se_cat3 

cat4_id 

category  4  ID 

more  specific  info  about  injury 

cat4_id  from  se_cat4 

geo_id 

geographic  ID 

unique  identifier  of  geographical 
location 

1  NE  Asia,  2  SW  Asia,  3 
Europe 

wnd_id 

WIA,  NBI,  or 
disease 

wounded  in  action,  nonbattle  injury 
or  disease 

1  WIA,  2  NBI,  3  Disease 

pc_id 

PC  ID 

patient  condition  ID 

pc_id  in  se_pc 

byinj_pro 

by  injury 

encrypted  injury  probability 

any  numeric  value 

byinj_id 

by  injury  ID 

unique  ID  for  by  injury  entry 

autogenerated  integer 

♦  TASKS 

The  se_task  table  identifies  the  task  number  and  the  description  of  each  task. 


Field 

Name 

Short  Name 

Description 

Values 

task_id 

task  ID 

unique  identifier  of  the  task 

autogenerated  integer 

task 

task  number 

the  old  number  of  the  task 

3  characters 

taskdesc 

task  description 

description  of  the  task  performed 

text 

The  se_pctsk  table  relates  patient  conditions  to  the  tasks  performed  on  those  conditions.  It  also 
describes  how  many  times  the  patient  requires  specified  treatment,  how  long  the  treatment  takes 
to  perform,  and  the  patient’s  length  of  stay. 


Field 

Name 

Kj 

Description 

Values 

pctsk_id 

pcfts  ID 

unique  identifier  of  records  in  the  table 

autogenerated  integer 

pc_id 

PC  ID 

patient  condition  ID 

pc_id  from  se_pc 

fa_id 

FA  ID 

functional  area  ED 

fa_id  from  se_fas 

task_id 

task  ID 

task  ID 

taskjd  from  se_task 

init 

init 

initial  number  of  times  treatment  is 
performed  on  patient 

integer 

recur 

recurring 

number  of  times  the  treatment  is  performed 
after  the  first  time  for  each  subsequent  24- 
hour  period 

integer 

alos 

average 
length  of 
stay 

the  length  of  time  in  hours  that  the  patient 
remains 

integer 

ttime 

treatment 

time 

the  time  in  minutes  it  takes  to  perform  the 
treatment 

integer 

♦  SUPPLIES 

The  se_supp  table  is  used  to  store  information  about  supplies.  The  table  provides  the  primary 
names  of  the  supplies  as  well  as  the  shortened  identifier  of  each  supply.  It  also  gives  the  weight, 
cubic  volume,  cost,  and  the  type  (whether  it  is  equipment,  medical,  consumable,  or  durable  item) 
of  each  supply. 


Field 

Name 

Short  Name 

Description 

Values 

supp_id 

supply  ED 

unique  identifier  of  the  supply 

autogenerated  integer 

nomen 

nomenclature 

short  name  of  supply 

text  (42  characters) 

org 

nomen 

original 

nomenclature 

longer  original  name  of  supply 

text 

nsn 

national  supply 
number 

a  supply  number  used  to  acquire  the 
supply  .  _ 

number  (13  characters) 

um 

units  of 

measure 

the  units  of  measure 

2  characters 

div_by 

divide  by 

the  number  of  supplies  in  a  package 

numeric 

weight 

weight 

the  unit  weight  of  the  supply 

numeric 

cube 

cube 

the  cubic  volume  of  the  supply 

numeric 

cost 

the  unit  cost  of  the  supply 

numeric 

ecd 

ECD 

the  type  of  supply  (equipment, 
consumable,  durable) 

1, 2,  or  3,  respectively 

i  s 


♦  UNITS  OF  MEASURE 

The  se_units  table  is  used  to  store  information  about  the  units  of  measure  of  each  supply. 


Field 

Name 

Short  Name 

Description 

Values 

unit_id 

unit  ID 

unique  identifier  of  the  unit  of 
measure 

autogenerated  integer 

um 

unit  of  measure 

abbreviation  for  the  unit  of  measure 

2  characters 

unitdesc 

unit  description 

description  of  the  unit  of  measure 

text 

♦  EQUIPMENT 

The  se_equip  table  may  be  used  to  relate  equipment  to  consumables  and  durables. 


Field  Name 

Short  Name 

Description 

Values 

eq_supp_id 

equipment 
supply  ID 

a  unique  identifier  of  equipment 

supp_id  from  se_supp 

cd_supp_id 

consumable  or 
durable  ED 

unique  identifier  of  consumable 
and  durables 

supp_id  from  se_supp 

♦  TASKS  ASSOCIATED  WITH  EACH  PATIENT  CONDITION 

The  se_pcfts  table  relates  to  several  other  tables  and  is  used  in  many  of  the  calculations 
involving  supplies.  It  provides  information  on  the  supply  quantity  necessary  for  the  specified 
patient  condition  and  task  within  that  functional  area. 


Field 

Name 

Short 

Name 

Description 

Values 

pcfts_id 

pcfts  ED 

unique  identifier  of  records  in  the  table 

autogenerated  integer 

pc_id 

PC  ED 

patient  condition  ED 

pc_id  from  se_pc 

fa_id 

FA  ID 

functional  area  ED 

fa_id  from  se_fas 

task_id 

task  ED 

task  ED 

task_id  from  se_task 

supp_id 

supply  ID 

supply  ID 

supp_id  from  se_supp 

loc 

LOC 

link  to  old  level  of  care 

character 

quant 

quantity 

quantity  of  supply  required  for  the 
associated  task  and  patient  condition  in 
the  identified  functional  area 

text 

♦  REPORTS  AND  QUERIES 

The  se_parm  table  is  used  to  store  information  about  parameters  required  for  ordering  and 
subtotaling  variables  in  the  output. 


Field 

Name 

Short  Name 

Description 

Values 

parm_id 

parameter  ID 

unique  ID  for  each  parameter 

autogenerated  integer 

rep_id 

report  ID 

foreign  key  to  report 

rep_id  from  se_reps 

ptype 

parameter  type 

type  of  parameter 

0  order,  F  filter,  S  subtotal 

parmdesc 

parameter 

description 

description  of  the  parameter 
to  be  displayed  to  users 

text 

o_desc 

order  descending 

the  order  is  descending;  for 
order  type  parameters  only 

true  or  false 

The  se_repgp  table  is  used  to  group  output. 


Field 

Name 

Short  Name 

Description 

Values 

repgp_id 

report  group  ID 

unique  identifier  of  records  in  the 
table 

autogenerated  integer 

rg_desc 

report  group 
description 

name  of  report  group  to  be 
displayed  to  users 

text 

The  se_reps  table  is  used  to  store  information  about  the  output  available  to  users. 


Field 

Name 

Short  Name 

Description 

Values 

report  ED 

unique  identifier  of  records  in  the  table 

autogenerated 

integer 

repdesc 

report 

description 

name  of  report  to  be  displayed  to  users 

text 

ESSEDI 

report  group  ID 

integer 

repfile 

report  file 

the  full  path  of  the  report  file 

frx  file 

w_scen 

with  scenario 

does  this  report  have  to  be  run  with  a 
scenario 

true  or  false 

repquery 

report  query 

the  code  run  to  query  the  database  and 
retrieve  the  data  for  the  report 

memo 

prgfile 

program  file 

the  full  path  of  the  program  file  that  is 
stored  in  repquery 

prg  file 

The  lv_rorq  is  a  local  view  that  accepts  two  parameters.  The  first  is  vp_rq  and  represents 
whether  the  user  wants  reports  or  queries.  The  value  may  be  either  true  for  reports  or  false  for 
queries.  The  second  parameter  is  vp_gp  and  is  a  character  representation  of  the  report  group  ID 
from  se_repgp.  The  view  is  used  to  display  the  reports  or  queries  in  the  currently  selected  group. 


Field 

Name 

Short  Name 

Description 

Values 

repdesc 

report  description 

a  description  of  the  report 

any  text  value 

rep_id 

report  ID 

unique  report  identifier 

rep_id  from  se_rep 

repgpjd 

report  group  ID 

unique  report  group  identifier 

repgpjd  from  se_repgp 

w_scen 

with  scenario 

does  the  report  require  a 
current  scenario  selection 

true  or  false 

The  se_sets  table  is  used  to  store  information  about  the  surgical  sets  and  where  they  are  located. 


Field 

Name 

Short  Name 

Description 

Values 

setjd 

set  ED 

unique  identifier  of  surgical  set 

autogenerated  integer 

taskjd 

task  ID 

task  identifier 

taskjd  from  sejask 

fajd 

FA  ED 

functional  area  ID 

fajd  in  se_fas 

sequence 

set  sequence  for  reporting 

integers 

numsets 

number  of  sets 

number  of  sets  per  functional  area 

integers 

setname 

set  name 

name  of  set 

text 

The  se_setsp  table  is  used  to  store  information  about  the  supplies  contained  in  each  set. 


Field 

Name 

Short  Name 

Description 

Values 

setspjd 

setsp  ED 

unique  identifier  of  the  set  supply 

autogenerated  integer 

setjd 

set  ID 

unique  identifier  of  surgical  set 

suppjd 

supply  ED 

unique  identifier  of  the  supply 

suppjd  in  se_supps 

quant 

quantity 

quantity  of  supply  in  the  set 

autogenerated  integer 

♦  THE  FOLLOWING  ARE  USED  AS  REFERENCES  FOR  OTHER  TABLES 

The  se_faeq  table  contains  the  quantity  of  supplies  within  a  functional  area.  It  is  also  used  to 
store  nonset  equipment  items. 


Field 

Name 

Short  Name 

Description 

Values 

FA 

functional  area 

@!3SEHi 

supply 

supply  identification 

quant 

quantity 

nonset  supply  quantity 

integer 

The  following  is  a  picture  of  the  sejbrief  table  that  stores  the  treatment  briefs  maintained  by  the 
Joint  Readiness  Clinical  Advisory  Board  (JRCAB).  The  briefs  are  stored  in  a  memo  field  for 
each  patient  condition. 


IsH 


2|Memo| 


}l.  Cerebral  concussion,  closed,  with/without  non- depressed  linear  skull  fracture,  severe - 
loss  of  consciousness  from  2  Jo  1 2  hours. 


LENGTH  OF  STAY  MATRIX; 

3 

ICU  2 
ICW  1 
MOW  1 
Total  4 

ECHELON  1 A 

Assumptions:  Litter  patient;  VS:  stable;  unconscious;  responsive  Jo  painful  stimuli; 
non-responsive  to  voice;  withdraws  with  pain;  no  focal  neurological  signs;  shallow 
respiration;  scalp  intact  no  other  apparent  injuries. 

Treatment  Oral  Airway,  Head  and  neck  stabilized  with  cervical  collar;  no  medications 
|  given;  urgent  transport  100%. 

|  ECHELON  10 

^  Assumptions:  Utter  patient  VS:  stable;  unconscious;  responsive  to  painful  stimuli; 


Sejbrief  table: 


Field 

Name 

Short  Name 

Description 

Values 

pcjd 

PC  ED 

pc  Jd  from  se_pc 

brief 

treatment  brief 

JRCAB  treatment  brief 

JRCAB  treatment  brief 

The  fa_tsk  table  is  used  to  display  the  tasks  and  functional  areas  where  they  are  performed.  This 
table  is  a  result  of  a  cross-tabulation  of  the  functional  areas  in  table  se_fas  and  the  tasks  in  table 
se  tasks. 


Field 

Name 

Short  Name 

Description 

Values 

taskjd 

task 

task  identifier 

taskjd 

firstresp 

first  responder 

first  responder 

true  or  false 

bas 

BAS 

Battalion  Aid  Station 

true  or  false 

frstriage 

FRS  triage 

Forward  Resuscitative  Surgery 

true  or  false 

frsor 

FRS  OR 

Forward  Resuscitative  Surgery 

true  or  false 

frspostop 

FRS  post  Op 

Forward  Resuscitative  Surgery  Post 
Operation 

true  or  false 

sctriage 

SC  triage 

true  or  false 

sc_or 

SC  OR 

true  or  false 

scward 

SC  ward 

Surgical  Company 

true  or  false 

scxray 

SC  X-ray 

Surgical  Company 

true  or  false 

sclab 

SC  lab 

Surgical  Company  Laboratory 

true  or  false 

K? 


The  se_fsow  table  is  used  to  report  PCs  treated  within  a  functional  area.  This  table  is  a  result  of  a 
cross-tabulation  of  the  functional  areas  in  table  se_fas  and  the  PCs  in  table  se_pc. 


Field 

Name 

Short  Name 

Description 

Values 

PC 

patient  condition  identifier 

pc_id 

first  responder 

first  responder 

true  or  false 

BAS 

Battalion  Aid  Station 

true  or  false 

frstriage 

FRS  triage 

Forward  Resuscitative  Surgery 

true  or  false 

frsor 

FRS  OR 

Forward  Resuscitative  Surgery 

true  or  false 

frspostop 

FRS  post  Op 

Forward  Resuscitative  Surgery  Post 
Operation 

true  or  false 

sctriage 

SC  triage 

Surgical  Company 

true  or  false 

sc_or 

SC  OR 

Surgical  Company 

true  or  false 

scward 

SC  ward 

Surgical  Company 

true  or  false 

scxray 

SC  X-ray 

Surgical  Company 

true  or  false 

sclab 

SC  lab 

Surgical  Company  Laboratory 

true  or  false 

The  fa_sup  table  is  used  to  display  each  supply  and  the  functional  areas  in  which  it  is  used.  This 
table  is  a  result  of  a  cross-tabulation  of  the  functional  areas  in  se_fas  and  the  supplies  in 
se_supp. 


Short  Name 

Description 

Values 

nsm 

supply 

supply  identifier 

supp_id 

first  responder 

first  responder 

true  or  false 

bas 

BAS 

Battalion  Aid  Station 

true  or  false 

frstriage 

FRS  triage 

Forward  Resuscitative  Surgery 

true  or  false 

frsor 

FRSOR 

Forward  Resuscitative  Surgery 

true  or  false 

frspostop 

FRS  post  Op 

Forward  Resuscitative  Surgery  Post 
Operation 

true  or  false 

sctriage 

SC  triage 

Surgical  Company 

true  or  false 

sc_or 

SC  OR 

Surgical  Company 

true  or  false 

scward 

SC  ward 

Surgical  Company 

true  or  false 

scxray 

SC  X-ray 

Surgical  Company 

true  or  false 

sclab 

SC  lab 

Surgical  Company  Laboratory 

true  or  false 

7.6  User  Interface 

The  level  0  user  has  access  to  only  those  areas  of  the  application  that  are  necessary  for  building  a 
patient  stream,  and  selecting  level  of  care,  functional  area,  and  output  type.  The  level  0  user  does 
not  have  access  to  the  database  in  order  to  maintain  database  integrity  and  reduce  user  confusion. 


8.  Design  Constraints 


Windows  Graphical  User  Interface  Standards  were  followed.  Object  Oriented  Programming 
techniques  were  employed  where  appropriate.  The  Visual  Classes  developed  for  and  used  in  this 
application  are  listed  below: 


Class 

Use 

Oleauto 

responsible  for  Microsoft  Office  automation  (controlling  Word  and  Excel) 

Se_vcx 

application  object  and  main  toolbar  object  classes 

Sfmapi 

email  class  allows  users  to  email  results  of  output 

Sfctrls 

controls  used  by  sfmapi 

Tdcntrls 

set  of  controls  that  allow  flexible  resizing  of  forms,  grids,  options 

Wizbase 

Microsoft  supplied  wizbase  class 

Wizbtns 

Microsoft  supplied  buttons  for  wizbase 

Wizembss 

Microsoft  supplied  class  to  give  wizard  embossed  look 

Btl 

Microsoft  supplied  application  class 

_base 

Microsoft  supplied  base  class 

bsshhi 

Microsoft  supplied  html  class 

Microsoft  supplied  html  style  class 

^movers 

Microsoft  supplied  mover  class 

9.  Security 

The  following  section  describes  the  system  security,  which  differentiates  between  NHRC  (level 
1)  users  and  general  users  (level  0). 

9. 1  Program  Developers 

The  system  stores  the  operator’s  userjd  and  user  level  (userlvl)  in  the  [se_user]  table.  NHRC 
users  are  given  a  level  1  (one);  all  other  users  are  given  a  level  0  (zero).  Users  assigned  a  security 
level  1  are  granted  access  to  maintenance  forms  (see  Section  10).  Users  assigned  a  level  0  are  not 
able  to  modify  the  output  formats,  and  they  have  read-only  access  to  data  files.  Probability  and 
user  password  values  are  safeguarded. 

9.2  General  Users/Custodians 

The  userjd  of  the  person  who  first  created  a  scenario  is  stored  in  the  table  of  scenarios 
[se_scen].  This  user  is  tagged  as  the  “custodian”  of  the  scenario.  The  application  keeps  track  of 
who  is  currently  logged  on  to  the  system.  If  the  current  user  is  also  the  custodian  of  the  scenario 
in  use,  the  system  allows  the  user  to  modify  the  scenario  (read-write  access).  If  the  current  user 
has  a  level  0  but  s/he  is  not  the  custodian  of  the  scenario,  the  application  allows  read-only  access 
to  the  user.  If  the  current  user  has  a  level  1,  the  system  allows  the  user  to  modify  any  scenario 
(read-write  access).  When  a  user  logs  on  for  the  first  time,  a  user  level  0  is  assigned 
automatically,  therefore,  allowing  the  user  to  read  existing  scenarios  and  create  new  ones.  On 


subsequent  log  ins,  users  can  create  new  scenarios,  modify  their  own  scenarios,  and  read  others’ 
scenarios. 

10.  Maintenance 

Users  granted  access  to  maintenance  (level  1)  may  perform  maintenance  on  output,  levels  of 
care,  functional  areas,  PCs,  and  data  import.  The  same  fundamental  steps  can  be  used  when 
maintaining  levels  of  care,  functional  area,  PCs,  and  the  data  import  screens. 

10. 1  Program  Maintenance 

The  first  form  available  for  program  maintenance  is  designed  to  update  tables  [se_fsow], 

[fa_tsk],  and  [fa_sup].  These  tables  show  functional  areas  where  PCs  are  treated,  functional 
areas  where  tasks  are  performed,  and  functional  areas  where  supplies  are  used,  respectively.  The 
maintenance  form  is  simply  three  check  boxes  and  a  command  button.  Level  1  users  check  the 
table(s)  to  update,  then  click  the  Update  command  button.  This  should  be  run  by  NHRC 
whenever  new  data  are  put  into  ESP  and  before  shipping  a  new  version. 

The  second  maintenance  form  is  designed  to  update  table  [se_faeq],  which  lists  the  functional 
areas  where  equipment  items  are  used,  and  the  quantities  of  equipment  items  that  are  not  part  of  a 
set.  Level  1  users  utilize  the  toolbar  to  move  through  the  records  (e.g.,  Back,  Next),  add  a  new 
record,  or  delete  a  record.  Level  1  users  can  also  change  the  field  of  an  existing  record. 

The  third  form,  described  below,  was  developed  to  allow  level  1  users  the  ability  to  create  their 
own  output  formats  while  in  the  application.  Programs  may  be  recompiled  and  tested  while  the 
application  is  running,  thus  avoiding  a  recompiling  operation  each  time  the  user  wants  to  modify 
a  query  or  report  format.  Level  1  users  can  maintain  new  levels  of  care,  PCs,  updated  tables,  and 
imported  data.  Users  assigned  a  level  0  are  not  able  to  modify  the  report  and  query  forms.  Below 
is  an  example  of  how  to  create  a  new  output  format: 

1.  Select  Maintain  Reports  from  the  main  menu  to  bring  up  the  report  and  query  form. 

2.  Click  the  New  button  on  the  toolbar. 

3.  Enter  a  unique  description  for  the  output. 

4.  Indicate  (check)  whether  the  output  must  be  tied  to  a  specific  scenario.  If  this  is  not  selected,  the  output 
reports  on  data  that  do  not  require  a  patient  stream. 

5.  Assign  a  group  name  to  allow  the  output  to  appear  when  the  user  selects  a  group. 

6.  Enter  the  name  of  the  program  file.  This  is  where  the  code  to  bring  all  of  the  data  together  for  the 
output  is  stored.  The  user  may  also  locate  an  existing  program  file  by  clicking  the  button  with  the 
ellipses  (...).  This  button  opens  a  dialog  allowing  the  user  to  find  the  file. 

7.  Enter  the  name  of  the  output  file.  This  is  where  the  output  format  is  stored.  Alternatively,  the  user  may 
locate  an  existing  output  format  by  clicking  the  button  with  the  ellipses  (...).  This  button  opens  a 
dialog  box  allowing  the  user  to  find  the  file. 

8.  Use  Edit  buttons  to  edit  the  output  after  it  has  been  created. 


9.  Enter  the  parameters  you  want  to  use  for  the  output,  within  the  grid. 

10.  First,  select  a  type.  Types  are:  F  =  Filter,  O  =  Order,  S  =  Subtotal.  The  type  determines  which  options 
the  user  is  presented  with  when  reporting. 

10  a.  A  filter  limits  the  output  to  a  specific  item.  For  example,  if  the  user  selects  Filter  and  enters 
field  name  fa_id,  then  the  output  presents  the  user  with  functional  areas  to  choose  when  reporting. 
10  b.  Order  gives  the  user  the  option  to  sort  the  results  by  the  field(s)  that  the  user  enters. 

10  c.  Subtotal  gives  the  user  the  option  to  subtotal  results  by  the  field(s)  that  the  user  enters. 

11.  Select  the  field  that  the  Filter,  Order,  or  Subtotal  should  operate  on  in  the  output.  You  must  enter  the 
field  names  exactly  as  they  are  in  the  database  table. 

12.  Enter  the  description  that  appears  to  the  user  to  explain  the  Filter,  Order,  or  Subtotal. 

13.  If  the  user  selects  Order,  the  user  may  select  Descending  to  allow  the  user  to  print  results  in  descending 
order. 

14.  All  of  these  selections  merely  modify  the  user  interface  to  present  options  to  users  running  this  output. 
To  make  these  meaningful,  the  program  and/or  output  must  employ  the  parameters  that  the  users  enter. 
Existing  programs  may  be  studied  for  examples  of  how  these  parameters  are  employed. 


1 1 .  Documentation 

This  system  is  detailed  by  means  of  this  system  document,  a  user’s  guide,  and  an  on-line  help 
facility  with  hypertext  capability.  Appendix  A  is  a  program  listing  of  the  code  run  to  generate  the 
reports  and  queries.  Appendix  B  is  a  690-page  code  diagram  listing  that  includes  Nesting  levels. 


12.  Future  Development  Opportunities 

Expand  the  algorithms  to  include  other  factors 

The  ESP  model  may  be  modified  to  include  number  of  shelters  to  deploy  and  number  of  patient 
treatment  positions  that  fit  in  a  shelter.  Furthermore,  ESP  can  be  broadened  to  include  many 
other  parameters,  such  as  number  of  pieces  of  equipment  per  shelter,  number  of  personnel 
available,  equipment  issued  to  personnel,  equipment  or  durable  consumption  per  patient  or  per 
bed,  and  number  of  uses  before  equipment  fails  or  needs  to  be  replaced. 

Load  data  into  the  system  to  handle  other  levels  of  care  and  functional  areas. 

The  model  may  be  expanded  to  handle  other  levels  of  care  by  determining  the  treatments  given 
at  new  functional  areas  and  adding  that  information  to  the  database. 

Add  databases,  queries,  and  reports  as  they  are  requested  by  users  after  delivery. 

After  delivery,  user  feedback  may  provide  important  guidance  as  to  how  NHRC  can  upgrade  the 
system  to  better  serve  its  users. 

Internet  enable  the  application. 

The  application  may  be  deployed  on  the  Internet  to  reach  a  more  global  audience. 


13.  Glossary 

Database  -  A  collection  of  Tables  and  Views  with  associated  stored  procedures. 

Entity  -  A  person,  thing,  or  abstract  business  concept.  In  database  design,  it  is  the  thing  that  the 
table  represents. 

Field  -  A  single  column  of  information  in  a  table. 

Foreign  Key  A  Primary  Key  from  one  table  that  is  in  another  table  to  establish  a  relationship 
between  the  two  tables. 

Patient  Condition  -  An  injury  or  disease  that  corresponds  to  a  patient  condition  code  number 
and  is  exhibited  by  a  patient. 

Patient  Stream  -  A  list  of  patient  conditions  and  the  associated  number  of  patients  exhibiting 
that  condition. 

Primary  Key  -  A  unique  identifying  value  in  a  record  of  a  table. 

Record  -  A  single  row  of  information  in  a  table. 

Scenario  -  A  situation  that  results  in  a  patient  stream.  Also,  often  used  as  a  synonym  of  patient 
stream. 

Stored  Procedure  -  Code  within  a  database  used  to  maintain  tables,  assign  key  values. 

Supply  -  A  piece  of  equipment,  durable  item,  or  consumable  item  that  is  used  in  the  treatment  of 
patients. 

Table  -  Information  about  a  particular  entity  stored  in  a  series  of  records  with  the  same  fields. 

Task  -  A  medical  procedure  performed  on  a  patient. 

View  -  The  updateable  result  of  a  query.  Several  views  are  stored  in  the  database.  A 

parameterized  view  requires  parameters  that  are  used  in  running  the  query  to  produce  the 
result.  An  example  of  a  parameterized  view  is  lv_addpcs,  which  accepts  the  current 
scenario  and  the  current  category  as  parameters  and  returns  the  set  of  patient  conditions 
in  the  current  category  that  are  not  included  in  the  current  scenario.  This  view  is  suitable 
for  selecting  patient  conditions  to  add  to  the  patient  stream. 
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13.  SUPPLEMENTARY  NOTES  ~  * 

14.  ABSTRACT  (maximum  200  words)  The  Naval  Health  Research  Center  (NHRC)  designed,  developed,  and  utilized  a  systematic 
process  to  review  the  Marine  Corps  medical  supply  requirements.  This  approach  identified  the  medical  tasks  required  to  treat  patients 
with  specific  injuries  and  illnesses,  and  determined  the  supplies  and  equipment  required  by  each  task.  To  determine  the  amount  of 
consumable  supply  requirements,  a  patient-generating  model  was  used  to  project  the  frequency  of  specific  injuries  and  illnesses  likely 
to  occur  in  theater.  Substantial  reductions  (approximately  30%)  in  the  number  of  items,  weight,  and  cube  were  achieved.  By 
establishing  the  clinical  requirement  for  each  item  pushed  forward,  the  NHRC  model  was  able  to  reduce  the  logistical  burden  carried 
by  Marine  Corps  units  and  enhance  far- forward  clinical  capability.  One  result  of  this  research  is  an  extensive  database  that  catalogues 
patient  conditions  (PCs)  and  the  tasks  and  supplies  required  to  treat  them.  NHRC  has  incorporated  the  research  and  the  database  into 
ESP  to  provide  users  with  the  ability  to  calculate  the  supplies  and  equipment  needed  to  treat  a  particular  patient  distribution.  This 
system  documentation  is  written  to  assist  ESP  users  with  planning  medical  resource  requirements  and  to  help  ESP  system 
administrators  at  NHRC  with  maintenance  of  the  database  and  enhancements  in  program  capability.  It  may  also  be  used  to  perform 
an  independent  verification  and  validation  of  system  capabilities.  ESP  uses  casualty  estimates,  levels  of  care,  and  functional  areas  to 
calculate  the  supplies  necessary  to  treat  a  defined  patient  stream.  ESP  is  capable  of  offering  the  following  levels  of  care:  First 
Responder,  Battalion  Aid  Station  (BAS),  Forward  Resuscitative  Surgery  (FRS)/Shock  Trauma  Platoon  (STP),  Surgical  Company 
(SC),  Small  Ships/Independent  Duty  Corpsman,  Submarines,  Landing  Ship  Dock/General  Medical  Officer,  LHA/LHD,  and  Aircraft 
Carriers.  ESP  also  offers  the  functional  areas  present  at  each  specific  level  of  care,  and  may  be  expanded  to  cover  all  the  listed  levels 
and  their  respective  functional  areas  in  the  future.  This  document  contains  a  general  description  of  ESP,  and  detailed  descriptions  of 
its  features  and  performance,  design  considerations,  interfeces,  security,  delivery,  installation,  maintenance,  and  future  development 
opportunities. 
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